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ABSTRACT 


We  examined  hardware  requirements  for  development  of  a  Deployable  Core 
Automated  Maintenance  System  (DCAMS).  Our  six  alternatives  covered  the 
spectrum  from  a  mainframe  computer,  the  Tactical  Shelter  System,  to  the  Air 
Force  standard  mi crocoraputer,  Zenith  Z-100.  Criteria  used  for  the  evaluation 
looked  at  ease  of  maintenance,  survivability,  physical  characteristics, 
transportability,  and  compatibility  with  CAMS.  We  recommend  using  a 
microcomputer  network  to  best  satisfy  the  hardware  requirement  for  DCAMS. 
Since  DCAMS  is  not  funded,  we  also  recommend  an  interim  system  be  developed  by 
the  AFLMC  to  provide  limited  support  until  DCAMS  is  ready.  The  system  would 
be  developed  on  the  AF  standard  microcomputer  and  provide  engine  tracking, 
scheduled  maintenance  requirements,  and  aircraft  status  information. 


EXECUTIVE  SUMMARY 


Ueve  lopment  of  a  Deployable  Core  Automated  Maintenance  System  (DCAMS)  will 
enhance  the  comhat  capability  of  aircraft  maintenance  units.  Therefore,  It  is 
vital  to  select  the  best  possible  hardware/software  combination  to  ensure 
rapid  and  cost  efficient  fielding  of  this  critically  needed  capability.  After 
reviewing  expected  future  maintenance  requirements  and  evolving  computer 
technology  we  developed  six  alternatives.  Based  on  our  analysis  of  these 
alternatives,  we  recommend  a  mi crocomputer  network  to  meet  DCAMS  needs. 

We  reviewed  the  current  methods  used  to  support  deployed  aircraft  maintenance 
units.  Aircraft  are  now  selected  by  a  deploying  unit  according  to  available 
f Lying  time  remaining  before  a  scheduled  major  maintenance  action  (engine 
change,  major  inspection,  etc.).  While  deployed,  if  a  phone  line  is 
available,  daily  calls  are  made  to  relay  flying  time,  maintenance  problems, 
and  engine  data  for  tracked  engines  to  the  home  base's  data  collection  system, 
other  ma intenance  data  is  generally  collected  for  input  upon  return  from  the 
deployment;  unfortunately,  large  amounts  of  data  are  frequently  lost.  For 
small  deployments,  12-14  aircraft  for  15-30  days,  the  aircraft  AFTO  Forms  781 
series  are  the  only  historical  records  generally  taken  along,  necessitating 
almost  total  reliance  on  the  home  station  for  any  other  maintenance  data  not 
contained  in  the  781.  Modular  engines,  such  as  the  F-100  engine  used  in  the 
1-16  and  K-15,  require  individual  components  be  tracked  to  ensure  none  are 
overflown.  We  have  determined  the  amount  of  time  required  to  make  all  the 
necessary  engine  component  calculations  and  are  confident  the  deployed  units 
do  not  do  them. 

The  alternatives  we  examined  were:  Null,  do  not  develop  DCAMS;  a  downsized 

Sperry  Emulator;  the  Tactical  Shelter  System;  a  minicomputer  (Combat  Supply 
System);  a  mi r rocomputer  network;  and  a  single  microcomputer  (Zenith  Z-10U). 
We  analyzed  each  alternative  using  size,  transportability,  cost  (initial  and 
life  cycle),  software  risk,  hardware  risk,  similarity  to  CAMS,  maintenance 
concept,  electrical  power  requirements,  survivability,  number  of  terminals, 
and  number  of  communications  ports.  A  detailed  summary  of  the  analysis  is 
attached  (Atch  1). 


A  microcomputer  network  provides  the  best  survivability,  is  easily 
transported,  and  is  flexible  enough  to  adapt  to  various  MAJCOM  management 
structures.  We  recommend  DCAMS  be  developed  as  a  stand-alone  network  for  use 
by  in  aircraft  ma i ntenance  unit  (AMU)  or  organizational  maintenance  squadron 
L  iMS )  t  light  line  section.  "Hie  network  would  perform  the  necessary  processing 
tor  t ne  unit  to  manage  assigned  aircraft.  It  would  be  connected  to  the  Phase 
IV  ,vst<  i  and  interact  with  CAMS  while  at  home  station,  and  operate  as  a 
1  ioa-ul  me  system  when  deployed. 

Ihi  •  ' -'incept  will  require  purchasing  of  specialized  microcomputers  capable  of 
•  >p. -i  it  ini'.  e|  t  i  ci  ently  in  a  network.  It  will  also  require  Air  Force 
P  i  •  ,r  .until- 1  to  become  proficient  in  distributed  processing  and  shared 
processing  to  develop  application  software.  As  no  money  has  been  approved  for 
Uh/vMS  development,  we  do  not  expect  to  see  an  operational  system  in  the  field 
t  >r  it  l<ast  three  years.  Field  units  that  can  be  deployed  cannot  wait  that 
long,.  Therefore,  we  recommend  an  interim  system  be  developed  to  provide  the 


minimum  capabilities  of  DCAMS.  This  system  would  only  be  capable  of  limited 
support  for  field  units.  As  a  minimum,  it  would  perform  aircraft  scheduling, 
engine  tracking,  and  status  monitoring.  The  first  two  programs  have  already 
been  developed,  leaving  the  status  module.  All  three  programs  can  be 
available  to  run  on  the  Z-100  computer  in  one  year. 
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CHAPTER  1  -  THE  PROBLEM 


1.  Background. 

a.  Maintenance  management  will  be  significantly  changed  when  the  Core 
Automated  Maintenance  System  (CAMS)  is  implemented.  Most  maintenance 
management  processes  are  paper  intensive  and  manually  accomplished  with  batch 
processed  computer  support.  Since  we  now  have  a  manual  input  system,  the  loss 
of  computer  support  either  at  home  station  or  during  deployments  has  minimal 
effect  on  management  processes.  The  manual  input  forms  are  collected  during  a 
power  outage  for  computer  entry  when  the  computer  is  back  up  or  during 
deployment  for  entry  when  the  unit  returns  to  home  station.  This  environment 
will  change  when  CAMS  becomes  operational. 

b.  CAMS  wilL  fulLy  automate  maintenance  management  by  providing  an 
on-line  computer  system  with  terminals  in  or  near  each  workcenter.  The 
majority  of  maintenance  data  will  be  entered  directly  by  the  originator  and 
retrieved  directly  by  the  user.  Supervisors  will  become  increasingly 
dependent  on  the  automated  management  processes,  and  our  young  airmen  will  be 
unfamiliar  with  how  to  follow  manual  procedures.  This  dependence  and  lack  of 
ramiliarity  will  make  returning  to  non-automated  data  systems  extremely 
ditficult  and  runs  the  risk  of  losing  valuable  maintenance  data. 

c.  During  deployments,  manual  data  systems  must  be  used  since  an 
automated  system  has  yet  to  be  developed.  CAMS  is  to  be  a  mainframe-based 
program  capable  of  use  only  on  the  Phase  IV  Sperry  1100/60  base  computer. 
Without  a  deployable  automated  system,  maintenance  personnel  will  be  forced  to 
revert  to  resource  consuming  procedures,  like  handwritten  logs,  when  resources 
are  limited  and  time  is  precious.  Therefore,  a  Deployable  Core  Automated 
Maintenance  System  (DCAMS)  must  be  developed.  The  Director,  Maintenance  and 
Supply,  HQ  USAF/LEY  tasked  the  AFLMC  to  compile  a  list  of  hardware/software 
options  for  DCAMS. 

2.  Problem  Statement. 

DCAMS  is  to  be  developed  by  the  Data  Systems  Design  Office  on  new  computer 
hardware  that  is  compatible  with  Phase  IV  equipment.  Many  types  of  hardware 
and  software  configurations  are  available  to  meet  the  DCAMS  requirement, 
however,  an  obvious  choice  Is  not  apparent  when  transportability,  ease  of 
operation,  cost  effectiveness,  and  compatibility  with  Phase  IV  CAMS  software 
are  considered. 

1.  Victors  Bearing  on  the  Problem. 

a.  Issues.  If  identical  systems  were  used  for  both  CAMS  and  DCAMS, 
development  anti  system  maintenance  costs  could  be  minimized.  DCAMS  and  CAMS 
wi  1  I  use  some  of  the  same  processes.  However,  the  computer  program  being 
developed  by  the  DSDO  for  CAMS  will  run  only  on  the  Sperry  Phase  IV  computer. 
To  run  on  any  other  computer,  the  source  code  would  have  to  be  translated. 
Ilia!  would  require  a  considerable  amount  of  time  and  resources. 


b.  Constraints. 
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(1)  Selected  equipment  must  be  easily  transportable  and  Immune  to 
most  environmental  conditions. 

(a)  Equipment  must  operate  on  available  electrical  power,  i.e.  , 
local  country,  generator,  etc,  110-220  VAC,  50-60  HZ.  Power  conditioning  can 
be  accomplished  internally  or  externally  to  system,  but  requirements  must  be 
considered. 

(b)  Individual  components  must  be  sized  to  be  easily  carried  by 
one  individual. 

(c)  Tempest  requirements  must  be  considered. 

12)  The  system  must  interface  with  existing  and  planned 
communicat ions  systems,  including  DON  and  satellite  terminals.  An  electronic 
interface  is  preferred. 

(3)  The  system  must  operate  in  a  stand-alone  mode  at  the  deployed 
iocation.  If  other  systems,  i.e..  Combat  Supply  System,  Combat  Logistics 
System,  etc.,  are  available,  electronic  data  exchange  capability  should  be 
considered. 

(M  As  a  minimum,  DCAMS  will  be  sized  to  support  one  squadron  (up  to 
24  aircraft)  per  system.  Expansion  to  wing  level  support  will  be  considered. 

(5)  The  equipment  must  be  compatible  with  CAMS  hardware  and  software. 
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CHAPTER  2  -  DEVELOPMENT 


Current  Method.  We  reviewed  the  current  methods  used  to  support  deployed 
.lircrut  i  itu  iiiten.ince  units.  Aircraft  are  now  selected  by  a  deploying  unit 
bused  on  available  flying  time  remaining  before  a  scheduled  major  maintenance 
<ict  ion  (engine  change,  major  inspection,  etc.).  While  deployed,  if  a  phone 
line  is  available,  a  daily  call  is  made  back  home  to  relay  time  sensitive  data 
such  as  flying  time,  maintenance  problems,  and  engine  data  for  tracked 
engines.  Other  routine  maintenance  data  is  generally  collected  for  input  upon 
••'turn  from  the  deployment;  unfortunately,  large  amounts  of  data  are 
et|  uciit  ly  lost.  For  small  deployments,  12-14  aircraft  for  15-30  days,  the 
aircraft  AFTO  Forms  781  series  are  the  only  historical  records  generally  taken 
along,  necessitating  almost  total  reliance  on  the  home  station  for  any  other 
maintenance  data  not  contained  in  the  781.  Modular  engines,  such  as  the  F-100 
engine  used  in  the  F-lb  and  F-15,  require  individual  components  be  tracked  to 
ensure  none  are  overflown.  We  have  determined  the  amount  of  time  required  to 
make  all  the  necessary  engine  component  calculations  and  are  confident  the 
deployed  units  do  not  do  them. 

horrent  procedures  are  inefficient  and  need  to  be  replaced  with  an 
automated  system.  Understanding  the  present  system  for  deployments  allowed  us 
Lo  develop  criteria  and  various  alternatives  for  examination. 

Me  t  liodo  logy  . 

a.  First,  evaluation  criteria  were  developed  using  the  technical 
expertise  of  our  analysts,  the  CAMS  Functional  Description,  DCAMS  Requirements 
Meeting  minutes,  and  other  data  sources  as  needed.  The  criteria  provided  a 
uniform  rating  system  for  evaluating  various  hardware  options. 

b.  Next,  data  on  hardware  capabilities  was  collected.  The  Combat  Supply 
System  request  for  proposal  was  reviewed.  The  AF  standard  microcomputer, 
Menith  2-lUO  capabilities  were  reviewed  at  the  AFLMC.  AFASPO  and  Sperry 
marketing  representatives  provided  information  on  Sperry  equipment.  Data  was 
gathered  on  other  hardware  to  determine  what  could  meet  the  DCAMS  requirement. 

•\  trip  to  Cherry  Point  Marine  Corps  Air  Station,  NC,  was  made  to  look  at  a  new 
deployable  system  being  developed  by  the  Navy. 

Finally,  the  various  hardware  options  were  evaluated  using  the  established 
ciiteria.  This  evaluation  determined  the  hardware  that  best  meets 

i  eq  n  i  rein. sits. 

'his  report  shows  the  selection  procedure  and  results. 

*•  '.valuation  Criteria.  Each  alternative  was  analyzed  to  determine  how  well 
it  in. - 1  a  set  of  criteria.  The  criteria  we  used  are  shown  below  along  with  a 
■  r i e t  de sc  r ipt ion. 

*•  Size.  DCAMS  is  a  deployable  system  mandating  an  easily  transportable 
'•"it.  Airlift  is  already  critical,  and  the  selected  hardware  should  not 
in ci. sise  airlift  requirements. 
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b.  Transportability.  Selected  hardware  must  be  easily  moved,  set  up,  and 
taken  apart.  No  special  handling  equipment  should  be  required.  Individual 
pieces  should  weigh  less  than  120  pounds  each.  Equipment  must  not  be 
susceptible  to  damage  in  transit.  Set  up  time  from  arrival  to  full  operation 
should  be  less  than  one  hour. 

c.  Cost.  Both  acquisition  cost  for  hardware  and  development  cost  for 
software  was  considered.  Software  maintenance  for  the  life  of  the  system  was 
also  considered  for  those  alternatives  requiring  separate  software  from  CAMS. 

d.  Maintenance  Concept.  DCAMS  hardware  should  be  maintainable  by  the 
user  with  self-diagnostic  software  to  the  circuit  card  level.  Less  than  eight 
hours  of  training  should  be  required  for  technicians  to  be  able  to  perform 
maintenance  on  the  hardware.  Systems  that  require  specialized  personnel  for 
maintenance  and  operation  were  considered  less  desirable. 

e.  KLectrical  Power  Requirements.  Hardware  should  be  switchable  to 
operate  on  l 10-220  VAC  50-60  HZ.  Power  conditioning  for  spikes,  etc.,  could 
he  performed  externally.  Battery  power  to  prevent  loss  of  data  in  case  of 
external  power  failure  should  be  provided. 

t.  Survivability.  The  equipment  should  not  be  an  obvious  target.  It 
tin  st  withstand  limited  shock/vibration  while  operating.  Some  redundancy 
should  be  included  to  ensure  continued  usability. 

g.  Number  of  Terminals.  Sufficient  terminals  should  be  available  for 
easy  access.  For  a  deployed  squadron  accustom  to  the  CAMS  environment,  seven 
to  ten  data  entry  devices  are  needed. 

h.  Number  of  Communications  Ports.  The  deployed  unit  will  be  required  to 
furnish  status  and  mission  data  to  home  base  and  higher  headquarters. 
Electronic  transfer  of  data  appears  to  be  the  most  efficient  method.  DCAMS 
should  electronically  interface  with  any  communication  system  (i.e.,  SATC0M, 
AUTODIN,  or  AUT0V0N)  available  at  the  deployed  location.  Also,  other  deployed 
svs terns  will  have  Important  data  needed  by  maintenance  or  vice  versa. 
Additional  ports  and  protocols  will  be  needed  to  communicate  electronically 
with  the  Combat  Supply  System,  Combat  Logistics  Systems  or  other  deployed 
computer  systems. 

A.  Evaluation  Factor.  We  also  used  the  following  factors  in  the  evaluation 
of  alternatives. 

a.  Software  Risk.  This  was  an  assessment  of  risk  to  develop  new  software 
which  is  dependent  upon  the  type  of  programs  being  developed.  Programs  using 
newly  developed  techniques  such  as  networking,  etc.,  have  higher  risk  than  a 
’’straight  forward"  program. 

b.  Hardware  Risk.  This  included  an  assessment  of  the  risk  of  the 
bn  r.jwn  re  in  each  alternative.  New  development,  i.e.,  an  emulator,  will  have  a 
greater  risk  than  commercially  available  hardware.  Also,  systems  emerging 
from  technology  have  greater  risk  than  established,  proven  systems. 

c.  Similarity  to  CAMS  Software.  The  direct  use  of  the  CAMS  software  for 
DCAMS  wi 1 1  reduce  the  amount  of  software  the  Data  Systems  Design  Office  has  to 
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mu  i  nt. i  i  n.  However,  ability  to  directly  use  the  CAMS  code  requires  specific 

computer  hardware  and  operating  systems,  thus  limiting  hardware  choices. 

5.  Alternatives.  The  following  six  possible  alternatives  were  analyzed, 
bach  alternative  is  presented  with  a  brief  description  and  discussed  as  to 
capability  to  meet  DCAMS  hardware  needs. 

a.  NULL,  Do  not  Develop  DCAMS.  Maintenance  managers  need  access  to  the 

data  presently  stored  in  the  base  mainframe  computer  system  on  a  daily  basis. 
During  deployments,  home  base  computer  access  is  not  available,  and  managers 
mist  perform  inefficient  manual  work-arounds.  Therefore,  this  option  does  not 
satisfy  management  needs  nor  satisfy  known  requirements  being  developed  in 
CAMS.  Deployed  units  with  new  aircraft  must  have  engine  tracking,  and  all 
units  need  scheduled  maintenance  data.  Under  CAMS,  maintenance  personnel  will 

rely  on  on-line  computer  systems  for  daily  support  at  home  base. 

Additionally,  they  will  have  to  be  familiar  with  manual  procedures  when  they 
revert  back  to  hand-scribed  records  when  deployed.  This  necessitates 
additional  training  and  results  In  decreased  effectiveness  when  maximum  combat 
capability  is  critical. 

b.  An  Emulator  CapabLe  of  Processing  CAMS  Software.  Computer  equipment 

to  satisfy  this  option  presently  does  not  exist.  This  system  would  run  the 
CAMS  software  since  it  would  electronically  emulate  an  1100/60.  Development 
of  this  capability  would  require  rights  to  the  Sperry  1100/60  computer 
operating  system  and  specific  hardware  design  data.  Without  access  to  that 

data,  it  would  be  impossible  for  any  company  except  Sperry  to  develop  an 

emulator.  This  could  force  us  into  a  sole  source  contract  effort. 

If  the  US  Government  has  rights  to  the  necessary  data,  a  competitive 
emu  rant  could  be  let  tor  system  deve lopment.  Litton  Data  Systems  developed 
an  emulator  of  the  Burroughs  B350U  computer  while  under  contract  with  the 
AH.MC.  Using  government-owned  data,  they  developed  the  emulator  in  about  lb 
months.  This  was  for  a  196Us  technology  computer  system.  The  Sperry  1  100/bU 
is  a  more  capable  computer  system  and  more  technologically  current  which 
increases  the  difficulty  of  developing  an  emulator  that  is  small  enough  to  be 
easily  deployable.  We  estimate  the  cost  at  between  two  and  five  million 
dollars  for  prototype  development.  A  production  system  would  probably  cost 
t rum  $300,000  to  $750,000  per  system.  These  estimates  are  based  on  the  cost 
to  develop  the  B33UU  emulator  and  the  projected  cost  per  unit. 

This  alternative  has  several  advantages.  One  set  of  software  for  CAMS  and 
DCAMS  ensures  a  unit  operates  the  same  at  home  station  and  when  deployed.  The 
sy  si."-,  is  identical;  no  additional  training  would  he  required  on  system 

* » j  >  o  r  . .  I  i  nil. 

v  ma j  >r  disadvantage  is  the  risk  associated  with  a  development  effort  and 
the  time  necessary  to  develop,  test,  and  procure  the  hardware.  Even  though 
CAMS  software  is  used  the  risks  may  outweigh  the  benefits. 

An  alternative  to  emulation  but  similar  approach  would  be  to  develop  the 
CAMS  software  on  a  separate  system.  To  the  user  it  would  appear  to  be  the 
same  system  but  written  to  be  run  on  separate  hardware.  The  disadvantage  to 
this  approach  is  the  introduction  of  addltonal  software  for  the  data  systems 


design  of t ice  to  maintain.  These  costs  could  be  reduced  through  modular 
software  design  by  having  some  joint  CAMS  and  DCAMS  processes  on  only  the 
L)C AMS  system  that,  while  used  at  home  station,  is  connected  to  Phase  IV. 

The  economic  analysis  for  CAMS  listed  life  cycle  costs  to  maintain  two 
sets  ot  software,  CAMS  and  DCAMS,  at  $10,000,000.  Modularizing  the  CAMS 
sottware  should  reduce  these  costs  as  some  options  in  CAMS  and  DCAMS  would  be 
in  only  one  place,  eliminating  the  need  for  duplicative  sets  of  software. 

c.  tactical  Shelter  System  (TSS).  The  TSS  is  a  Sperry  1 100/60  computer 
built  into  four  air  transportable  shelters.  Each  shelter  provides  its  own 
environmental  cotiLroL  and  power  source.  This  system  would  add  one  C-141  load 
to  each  deploying  squadron's  equipment.  With  each  unit  usually  constrained  on 
the  .urn  in  ill  of  airlift  programmed  and  with  documented  shortfalls  in  total 
airlift  during  actual  contingencies,  extra  airlift  is  not  guaranteed  to  add 
this  required  capability. 

The  TSS  is  also  very  costly.  Each  system  is  projected  to  cost  $2,800,000. 
Ibis  is  ■  total  of  $590,000,000  for  211  systems,  the  required  number  of  DCAMS 
•.•slums  I  mm  the  DCAMS  delivery  schedule,  dated  24  May  83. 

Common  sottware  is  a  distinct  advantage  and  does  offset  procurement  cost 
with  reduced  lifecycle  costs  for  maintenance  of  a  separate  DCAMS  software 
package.  As  previously  stated  that  cost  is  $10,000,000  for  20  years. 

This  alternative  was  rejected  due  to  airlift  requirements,  which  would 
increase  the  projected  airlift  shortfall,  and  system  cost.  Even  with  the 
offsetting  cost  of  having  only  one  set  of  software  to  maintain,  this  option  is 
ext reme ly  expensive. 

d.  -1  i  hi  computer.  The  original  requirements  for  the  Deployable  Combat 
Support  Systems  (Combat  Supply  System)  were  used  as  the  baseline  for  this 
option.  The  Combat  Supply  System  (CSS)  procurement  is  in  final  contract 
negotiations.  The  hardware  is  expected  to  be  a  minicomputer  with  at  least 
seven  terminals.  Projected  costs  are  less  than  $100,000  per  system  for  about 
/'i  u  vs  terns. 

Tin-  CSS  wi  L 1  be  used  as  a  front-end  processor  with  a  Phase  IV  computer  at 
base  level.  [hose  units  tiiat  are  authorized  a  War  Readiness  Spares  Kit  (WRSK) 
will  ii.iv>'  a  CSS  assigned.  All  WRSK  management  on  a  day-to-day  basis  will  be 
performed  in  the  CSS.  Trio  CSS  will  exchange  data  automatically  with  the 

■  >t  i  ‘l.i  r '1  Base  Supply  System  on  the  Phase  IV  Sperry  1  100/60  computer.  When  the 

is  deployed  with  the  assigned  unit,  the  CSS  will  he  disconnected  from  the 

■  'peri''  1  C'D/'iO  and  deployed.  it  will  provide  a  WRSK  management  system  for  the 
deployed  unit  independently  for  up  to  t>0  days  along  with  other  capabilities. 

I  ho  system  fias  been  specified  in  the  request  for  proposal  to  be  easy  to 
if  tin  and  very  reliable.  The  user  will  have  diagnostic  software  to 
i  r  '-ib  le  Minor  tiie  system  and  isolate  malfunctions  to  the  replaceable  unit. 

1 h i s  option  does  meet  most  of  the  criteria  necessary  for  a  DCAMS  system, 
it  i>  eisily  deployable  and  the  cost  Is  not  prohibitive.  The  CSS,  or  a 
simi  1  ir  minicomputer,  wouLd  require  a  new  set  of  software.  By  using  the 


Lcrhni  being  planned  lor  the  CSS ,  some  portions  ot  the  CAMS  software  could 

he  resilient  ..rly  >i>  a  minicomputer  system  in  the  local  unit  and  never  be 

included  in  CAMS  on  the  Phase  IV  computer.  This  reduces  the  amount  of 

duplicative  software  tor  CAMS  and  DCAMS.  DCAMS  programs  would  run  on  the 
DC  AMS  hardware  at  home  station  interfacing  directly  with  CAMS  and 
independently  when  disconnected  from  CAMS  and  deployed. 

Tiie  major  disadvantage  of  this  system  is  the  characteristics  of  a 
mi ni computer .  Having  a  single  minicomput  r  with  a  single  cent  ral  processing 
unit  (CPU)  increases  the  probability  ot  system  outage  due  to  malfunctions  or 
damage.  The  high  reliability  and  planned  user  maintenance  concept  can  not 
completely  eliminate  system  downtime.  Maintenance  managers  will  become 
increasingly  dependent  on  the  system  once  it  becomes  available.  Loss  of  the 
system  will  great ly  compound  management  problems  after  several  years  of  a 
tally  automated  management  environment,  both  at  home  station  and  when 
deployed.  Reverting  to  manual  procedures  will  be  extremely  cumbersome  and 

i  ue  t  feci  :  . 

this  ilternative  tor  a  minicomputer  is  rejecLed  for  the  lack,  o  t 

i.irvi vabl ! i tv  and  redundancy  inherent  to  the  system.  This  alternative  does 
•ie<  '  i  ue  needs  tor  a  DCAMS  system  but  compared  against  all  alternatives,  the 
s  t  u, ;  1  .•  mi u : computer  does  not  provide  the  redundancy  of  a  microcomputer 
network.  Here,  it  a  CPU  becomes  inoperable  tor  any  reason,  all  processing 
>:  f  i  ;  'in  system  is  down  until  the  CPU  is  repaired. 

Microcomputer  Network.  Any  microcomputer  system  that  can  efficiently 
ope’ ate  in  a  local  area  network  was  included  in  this  option.  A  microcomputer 
-  .1  stand-alone ,  table  top-size  computer,  usually  with  one  keyboard  and  visual 
:  i  s;>  lay  r.  :  uinal.  Memory  size,  disk  devices  and  other  peripherals  will  v.->  .*  y 

; .  i  ■.  i !  id  irer  and  system  configuration.  Local  area  networks  (LAN)  allow 
.  ■  ra  1  Tiicrocomputets  to  be  connected  in  a  circuit  to  share  programs  and  data 
v’  ,  :  •  r-.-taining  the  capability  to  operate  independently.  If  one  computer 
a. :  I  ‘  in.,  t  ions ,  the  remaining  computers  on  the  LAN  wi '  1  be  able  to  continue  to 
op,-  iic.  The  LAN  uses  one  of  the  microcomputers  as  a  network  controller  to 
'  o-  •  c  ir.ioanicat  ions  on  the  LAN  are  possible;  however,  the  controller 
iui'  '  an  he  shifted  to  another  microcomputer. 

I  L ;  •  t.  ion  il-io  requires  an  additional  set  ot  DCAMS  software.  Using  the 

no  ■  ■ ,  ■ :  it  >pt  i  mum  W  t  icier.cy ,  the  DCAMS  LAN  should  be  used  daily  in  the  unit 
i-  i  port  "t  CAMS.  Some  functions  now  planned  for  Inclusion  in  CAMS  programs 
":ld  hr  t.-vel  oped  tor  use  only  on  the  DCAMS  hardware.  Those  units  without  a 
I-  p  I  >.■ ■  r  '.ission  could  use  the  same  system  as  a  front-end  processing  system 
1  .  - :  :  I  i r  hardware  that  was  not  built  for  deployment  (commercial  version). 

■  pi  .i!>;  lity  and  survivabi  l  ity  are  enhanced  with  a  LAN  and  a 
m ;  -  r.'oiip  i  r  ■■  r .  Systems  currently  available  have  the  demonstrated  capability 

:  ••  -t  DCAMS  reijui  r. -meets  tor  a  multitask  computer  system  that  will  operate 
et  I  i.  ;ei.(  i  ,■  a  LAN.  With  the  known  delay  in  DCAMS  funding,  the  variety  and 
■  ■  ipibi  lii-.  i.i  comme  rc  i  a  I  ly  available  systems  will  dramatically  increase, 
i  '  i  -  ■  .  t  ■  ems  will  reduce  the  risk  and  cost  for  this  option.  Very  capable 

nii  i '■'"input '-rs  are  comme  rc  ia  l  1  y  available  and  easily  transportable.  They  are 
genera  1  I  y  small,  self-contained  units  with  large  memory  and  data  storage 
capa.  ity.  Repackaging  to  enhance  ruggedness  and  transportability  is  feasible 
’hr>>  i.li  c. infract  spec  i  t  i  cat  ions  ,  but  not  without  adding  cost. 


Govern  nent  and  commercial  installations  of  LAN’s  are  increasing  rapidily. 
A  [>AN  is  presently  being  brought  into  the  Air  Force  through  a  project  at 
Gunter  AFS.  The  Data  System  Design  Office  is  managing  the  instaliatlon  of  a 
LAN  that  wilL  interconnect  many  users  at  widely  seperated  locations  on  the 
base  using  off  the  shelf  equipment.  Commercial  installations  interconnecting 
large  office  buildings  or  complexes  are  becomming  common  place.  IBM  has 
announced  an  IBM  PC  network  that  will  be  available  in  early  1985.  In  an 
article  from  the  20  Aug  1984  issue  of  Computerwor Id ,  Joseph  Hughes  marketing 
vice-president  of  Corvus  systems,  Inc  stated  "I  predict  a  fivefold  increase  in 
personnel  computer  network  installations  in  the  next  year."  Proven  systems 
will  be  available  to  meet  all  DCAMS  needs. 

Multiple  microcomputers  for  a  DCAMS  system  allows  several  fallback 
positions  in  the  event  of  equipment  malfunction  or  damage.  A  full 
configuration  would  entail  5-10  microcomputers  on  a  LAN.  Several  computers 
could  be  lost  without  total  disruption  of  the  LAN,  and  each  microcomputer 
would  still  have  the  capability  to  operate  independently.  Disruption  of  the 
LAN  would  allow  individual  computers  to  process  and  collect  data  in  the 
stand-alone  mode,  but  distributed  processing  and  data  transfer  may  be  lost  to 
some  stations  while  the  LAN  is  being  repaired.  As  ali  the  microcomputers 
would  be  identical,  all  independent  programs  could  run  on  any  computer,  giving 
great  flexibility  in  maintaining  residual  processing  of  essential  functions 
until  the  LAN  and  individual  computers  could  be  repaired. 


Microcomputers  and  LAN  technology  are  advancing  rapidly  with  an  associated 
decrease  in  prices.  A  LAN  with  up  to  seven  microcomputers  could  be  purchased 
in  an  off-the-shelf,  commercial  configuration  for  about  $32,000  per  system. 

f.  Microcomputer.  A  single  microcomputer,  specifically  the  Air  Force 
standard  microcomputer,  the  Zenith  Z-100,  was  evaluated  in  this  option.  The 
single  microcomputer  is  fully  capable  of  performing  many  necessary  functions 
in  a  deployed  environment.  It  is  easily  deployed  and  maintained  by  users.  It 
is  planned  that  the  Z-100  will  be  able  to  interface  directly  with  the  Sperry 
1100/60  in  the  CAMS  environment  and  function  as  a  smart  terminal,  being  able 
to  independently  process  data  from  the  mainframe 

The  greatest  deficiency  with  the  use  of  a  single  microcomputer  for  DCAMS 
is  the  inability  to  pass  data  electronically,  automatically,  and  efficiently. 
Distributed  processing  using  a  LAN  entails  shared  data  that  is  accessed 
automatically  as  specific  application  programs  require  it.  A  single 
microcomputer  can  pass  data  files  electronically,  and  the  individual  computer 
can  then  run  its  own  programs  using  that  data.  The  data  transfer  is  usually 
not  lully  automated  and  some  operator  input  Is  required.  This  deticiency 
could  necessitate  numerous  transfers,  or  the  manual  Input  of  data  to  ensure 
the  most  current  data  is  used.  This  makes  a  system  of  Independent 
microcomputers  too  cumbersome  for  this  operation. 

Access  to  terminals  to  input  or  retrieve  data  is  more  difficult  when  using 
single  microcomputers.  Different  managers  and  technicians  may  use  the  same 
data  In  various  ways.  Each  must  have  access  to  some  common  data  and  yet  have 
exclusive  data.  The  common  data  would  have  to  be  entered  into  each  machine 
independently.  This  approach  may  create  backlogs  and  inaccurate  data  files. 


These  limitations  cause  rejection  of  the  single  microcomputer  option 


5.  The  project  team  also  created  the  following  matrix,  Fig  2-1,  to  permit 
easier  comparison  of  alternatives.  The  chart  shows  physical  characteristics 
of  the  evaluated  systems. 


PHYSICAL  CHARACTERISTICS  OF  OPTIONS 


COMPATIBLE 

PER  SYSTEM  WITH 


PRICE 

APPROXIMATE 

SIZE 

ELECTRICAL 

POWER 

NUMBER  OF 
TERMINALS 

CAMS 

SOFTWARE 

CAMS 

DATA 

I 

OPTION 

EMULATOR 

$300-750 

K  Table  Top 

CPU  (1) 

110/220 

10-50 
as  needed 

Yes 

Yes 

TSS 

$2,800  K 

4  Large 

Vans 

110/220 

Generator 

50+ 

as  needed 

Yes 

Yes 

MINI¬ 

COMPUTER 

(CSS) 

$60-80  K 

Table  Top  (1) 
CPU  (2) 

110/220 

7 

No 

Yes(4) 

MICRO¬ 

COMPUTER 

NETWORK 

$32  K 

Size  Of 

8  Micro 's(3) 

110/220 

7 

No 

Yes(4) 

MICRO¬ 

COMPUTER 

$5  K 

Size  of 

Micro 

110/220 

1 

No 

Yes(4) 

NOTE:  L.  CPU  would  fit  on  desk.  Peripherals  (hard  disk  drive,  line  printer, 

system  controller,  etc)  would  add  to  space  needed,  terminals  extra. 

2.  CPU  would  fit  on  desk,  terminals  extra. 

3.  Based  on  existing  hardware. 

4.  Can  be  programmed. 


Figure  2-1 


14 


CHAPTKR  3 


CONCLUSIONS 


The  nail  alternative  of  not  developing  DCAMS  is  infeasible  because  of  the 
changes  coining  in  CAMS  over  the  next  four  to  five  years.  If  we  do  nothing  to 
cover  when  the  full  system  is  down  or  unavailable  (like  when  a  unit  is 
deployed),  we  may  (or  will)  not  be  able  to  cope  with  manually  processing 
maintenance  information  needed  to  perform  the  mission  (like  tracking  the 
modules  on  the  F-100  engine  to  keep  the  aircraft  flying).  Therefore,  the 
question  is  not  whether  a  deployable  system  should  be  developed,  but  what 
hardware  should  be  used  for  a  DCAMS. 

Our  analysis  of  the  various  types  of  hardware  systems  easily  ruled  out 
several.  The  Tactical  Shelter  System  is  too  large  because  it  would  add  a 
C  —  1 4 1  load  to  each  deploying  squadron.  The  single  microcomputer  is  too 
limited  to  support  all  of  its  requirements,  and  has  only  one  keyboard  and  CRT. 
The  emulator  of  a  Sperry  1100/60  mainframe  computer  has  major  advantages  over 
other  options.  Although  it  would  run  CAMS  software  and  could  be  designed  for 
easy  deployment,  it  could  not  be  available  until  1990.  We  need  DCAMS  before 
then;  therefore  the  emulator  option  is  unacceptable.  Of  the  remaining 
options,  even  though  the  hardware  for  the  Combat  Supply  System  meets  most 
needs,  it  appears  the  hardware  will  be  a  minicomputer  and  is  eliminated  for 
survivability.  Loss  of  the  central  processing  unit  would  leave  the  deploying 
unit  with  no  support.  The  remaining  option,  microcomputer  network  is  selected 
as  best  satisfying  our  criteria. 


CHAPTER  4 


RECOMMENDATION 


A  microcomputer  network  provides  the  best  survivability,  is  easily 
transported,  and  is  flexible  enough  to  adapt  to  various  MAJCOM  management 
structures.  The  network  would  perform  the  necessary  processing  for  the  unit  to 
manage  assigned  aircraft.  It  would  be  attached  to  the  Phase  IV  system  and 
interact  with  CAMS  while  at  home  station,  and  operate  as  a  stand-alone  system 
when  deployed.  Recommend  DCAMS  be  developed  as  a  stand-alone  network  to  be 
used  by  an  aircraft  maintenance  unit  (AMU)  or  organizational  maintenance 
squadron  (QMS)  flight  line  section.  (OPR:  HQ  USAF/LEY) 

This  concept  will  require  the  purchasing  of  specialized  microcomputers 
with  tlie  capability  to  operate  efficiently  in  a  network.  It  will  also  require 
Air  Force  programmers  to  become  proficient  in  distributed  processing  and 
shared  processing  to  develop  application  software.  As  no  money  has  been 
approved  for  DCAMS  development,  we  do  not  expect  to  see  an  operational  system 
in  the  field  for  at  least  three  years.  Field  units  with  a  deployment  mission 
wiLL  not  be  abLe  to  wait  that  long.  An  interim  system  could  be  available  to 
run  on  a  Z-100  computer  in  one  year.  This  system  would  only  be  capable  of 
limited  support  for  field  units.  As  a  minimum,  it  would  perform  aircraft 
scheduling,  engine  tracking,  and  status  monitoring.  The  first  two  programs 
have  already  been  done,  leaving  the  status  module  to  develop. 

The  AFLMC  would  provide  the  computer  programs  and  user's  manuals  to 
MAJCOMs  needing  the  interim  system.  We  would  provide  maintenance  of  the 
computer  program  to  ensure  it  will  continue  to  function  until  the  Air  Force 
DCAMS  system  is  ready.  Software  maintenance  would  include  both  support  to 
keep  the  system  operating  and  essential  enhancements. 

The  interim  system  would  consist  of  three  parts.  We  would  integrate  the 
Automated  Flying  and  Maintenance  Scheduling  System,  (AFAMS),  Minimum  Essential 
Engine  Tracking  System  (MEETS)  and  a  third  module  to  perform  status  and 
history  tracking.  We  envision  the  system  would  carry  sufficient  aircraft 
history  from  home  station  to  satisfy  maintenance  managers.  All  work  orders 
would  be  entered  and  stored  in  the  system  providing  a  completed  history  while 
dep  loyed . 

This  would  only  provide  a  limited,  interim  capability.  It  is  not  designed 
to  replace  DCAMS  but  to  provide  some  computer  support  until  DCAMS  can  be 
funded  and  developed.  The  Air  Force  has  passed  the  point  where  a  unit  can 
deploy  and  operate  efficiently  without  some  computer  support.  Implementation 
of  CAMS  will  make  a  deployment  harder  if  maintenance  personnel  have  to  revert 
from  an  on-line  computer  system  to  manual  procedures. 

We  recommend  development  of  an  interim  system  to  provide  minimum 
capabilities.  (OPR:  AFLMC) 
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